15장. RAG 품질을 높이는 방법

1. RAG 품질은 답변만 보고 판단하면 안 된다

RAG를 만들고 나면 보통 이렇게 테스트한다.

사용자 질문:
하트 충전 후 반영이 안 되면 어떻게 처리해?

AI 답변:
먼저 PG 승인 여부를 확인하고, 승인 완료 후 충전 내역이 없으면 충전 처리 로그를 확인해야 합니다.

답변이 그럴듯하면 “잘 되네”라고 생각하기 쉽다.

하지만 RAG 품질은 답변만 보고 판단하면 안 된다.

RAG는 크게 두 단계로 동작한다.

1. 검색
사용자 질문과 관련 있는 문서를 찾는다.

2. 생성
검색된 문서를 바탕으로 AI가 답변을 만든다.

따라서 답변이 이상할 때 원인은 두 가지 중 하나일 수 있다.

- 검색이 잘못되었다.
- 검색은 맞았지만 AI가 답변을 잘못 만들었다.

예를 들어 사용자가 이렇게 물었다고 해보자.

회원 탈퇴 후 재가입은 언제 가능해?

AI가 이렇게 답했다.

회원 탈퇴 후 30일 동안 재가입할 수 없습니다.

이 답변이 틀렸다고 가정하자.

원인은 검색일 수도 있다.

검색된 문서:
2023년 회원 탈퇴 정책 문서

이 경우 AI가 오래된 문서를 보고 답한 것이다.
문제는 AI가 아니라 검색 대상 문서나 최신 문서 우선순위일 수 있다.

반대로 검색은 제대로 됐을 수도 있다.

검색된 문서:
2026년 회원 탈퇴 정책 문서
- 회원 탈퇴 후 7일 동안 재가입 제한

그런데 AI가 30일이라고 답했다면 생성 단계의 문제다.

프롬프트가 약했거나, 검색된 문서 외의 일반 지식을 섞었을 수 있다.

그래서 RAG 품질을 볼 때는 항상 이렇게 나눠야 한다.

검색 품질:
올바른 문서를 찾았는가?

답변 품질:
검색된 문서를 근거로 정확히 답했는가?

이 장에서는 RAG 품질을 높이기 위해 무엇을 점검하고 개선해야 하는지 살펴본다.

2. RAG 품질 평가의 기본 흐름

RAG 품질을 개선하려면 감으로 보면 안 된다.

“대충 잘 되는 것 같다”는 판단은 위험하다.

테스트 질문을 만들고, 기대 문서와 기대 답변을 정리해야 한다.

기본 흐름은 다음과 같다.

1. 실제 사용자가 물어볼 질문을 모은다.
2. 각 질문에 대해 기대 문서를 정한다.
3. RAG 검색 결과에 기대 문서가 포함되는지 확인한다.
4. AI 답변이 문서 내용과 일치하는지 확인한다.
5. 실패한 케이스를 검색 문제와 생성 문제로 나눈다.
6. 원인에 맞게 개선한다.

예를 들어 고객센터 RAG를 만든다고 해보자.

테스트 질문은 다음처럼 만들 수 있다.

질문 1:
하트 충전했는데 반영이 안 됐어요. 어떻게 처리해?

기대 문서:
결제 실패 및 하트 미반영 처리 매뉴얼

기대 답변:
PG 승인 여부 확인
충전 처리 로그 확인
재처리 대상 판단
이미 사용된 하트는 환불 제외

또 다른 질문도 만든다.

질문 2:
이미 사용한 하트도 환불 가능한가요?

기대 문서:
환불 처리 기준
하트 사용 및 환불 예외 정책

기대 답변:
이미 사용된 하트는 원칙적으로 환불 대상에서 제외
다만 결제 오류나 중복 결제 여부는 별도 확인

이렇게 질문별 기대 문서와 기대 답변을 정리해두면 RAG 품질을 객관적으로 볼 수 있다.

RAG 테스트는 단순히 AI 답변이 예쁜지 보는 것이 아니다.

- 기대한 문서가 검색되었는가?
- 답변이 문서와 일치하는가?
- 문서에 없는 내용을 말하지 않았는가?
- 출처가 맞게 표시되었는가?
- 모르는 질문에는 모른다고 답했는가?

이 기준이 있어야 개선 방향도 명확해진다.

3. 테스트 질문 세트를 만들어야 한다

RAG 품질 개선의 출발점은 테스트 질문 세트다.

테스트 질문은 실제 사용자가 물어볼 만한 질문이어야 한다.

개발자가 문서 제목 그대로 만든 질문만 있으면 품질을 제대로 평가하기 어렵다.

예를 들어 문서 제목이 다음과 같다고 해보자.

결제 실패 및 하트 미반영 처리 매뉴얼

개발자는 이렇게 질문할 수 있다.

결제 실패 및 하트 미반영 처리 절차 알려줘.

이 질문은 문서 제목과 거의 같다.

검색이 잘될 가능성이 높다.

하지만 실제 사용자는 이렇게 물을 수 있다.

하트 충전했는데 안 들어왔대.

카드 결제는 됐는데 하트가 없다고 해.

결제 문자는 왔는데 충전이 안 됐다는데?

BJ한테 후원하려고 충전했는데 잔액이 안 늘었대.

이런 질문도 잘 찾아야 RAG가 실무에서 쓸 만하다.

테스트 질문 세트에는 다양한 표현이 들어가야 한다.

- 문서 제목과 비슷한 질문
- 사용자가 실제로 말할 법한 질문
- 오타가 있는 질문
- 줄임말이 있는 질문
- 여러 문제가 섞인 질문
- 답이 문서에 없는 질문
- 권한이 필요한 질문

예를 들어 다음처럼 구성할 수 있다.

좋은 테스트 질문 세트가 있어야 RAG를 안정적으로 개선할 수 있다.

4. 검색 품질을 먼저 확인해야 한다

RAG 답변이 이상하면 가장 먼저 검색 결과를 봐야 한다.

AI 답변만 보면 원인을 알 수 없다.

예를 들어 사용자가 이렇게 물었다고 하자.

방송방 입장이 안 되면 어디부터 확인해야 해?

좋은 검색 결과는 다음과 같다.

1. 방송방 입장 장애 대응 매뉴얼
2. WebSocket 연결 오류 확인 절차
3. Redis timeout 대응 문서

나쁜 검색 결과는 다음과 같다.

1. 방송 제목 변경 가이드
2. 방송 종료 처리 API 문서
3. 방송 카테고리 운영 정책

검색 결과가 틀렸다면 AI가 아무리 좋아도 제대로 답하기 어렵다.

검색 품질을 볼 때는 다음을 확인한다.

- 기대 문서가 검색 결과에 포함되어 있는가?
- 기대 문서가 상위 몇 번째에 있는가?
- 관련 없는 문서가 많이 섞였는가?
- 오래된 문서가 최신 문서보다 위에 있는가?
- 권한 없는 문서가 검색되었는가?
- 같은 문서의 중복 chunk가 너무 많이 나오는가?

검색 결과는 사용자에게 바로 보이지 않을 수 있지만,
RAG 내부에서는 반드시 확인 가능해야 한다.

운영 로그에 다음 정보를 남기면 품질 개선에 도움이 된다.

- 사용자 질문
- 검색된 chunk ID
- 검색 점수
- 문서 제목
- 문서 수정일
- 문서 상태
- 사용자 권한

검색 결과를 볼 수 없으면 RAG 품질 개선이 어렵다.

답변이 틀렸을 때 검색이 문제인지, 생성이 문제인지 알 수 없기 때문이다.

5. 기대 문서가 검색되는지 확인한다

검색 품질의 가장 기본 지표는 기대 문서가 검색 결과에 들어오는지다.

예를 들어 질문과 기대 문서가 다음과 같다고 하자.

질문:
하트 충전했는데 반영이 안 됐어요.

기대 문서:
결제 실패 및 하트 미반영 처리 매뉴얼

검색 결과가 다음과 같으면 좋다.

top 1:
결제 실패 및 하트 미반영 처리 매뉴얼

top 2:
PG 승인 확인 절차

top 3:
충전 처리 로그 확인 방법

하지만 다음과 같으면 개선이 필요하다.

top 1:
하트 후원 이벤트 정책

top 2:
하트 랭킹 노출 기준

top 3:
방송 후원 알림 설정

이때 사용할 수 있는 간단한 평가 방식이 있다.

top 1 정확도:
기대 문서가 검색 결과 1번째에 있는가?

top 3 포함률:
기대 문서가 상위 3개 안에 있는가?

top 5 포함률:
기대 문서가 상위 5개 안에 있는가?

예를 들어 테스트 질문 100개를 만들었다고 하자.

기대 문서가 top 1에 있음: 62개
기대 문서가 top 3 안에 있음: 81개
기대 문서가 top 5 안에 있음: 90개

그러면 대략 이렇게 볼 수 있다.

top 1 정확도: 62%
top 3 포함률: 81%
top 5 포함률: 90%

처음부터 완벽할 필요는 없다.

중요한 것은 기준을 가지고 개선하는 것이다.

변경 전:
top 3 포함률 72%

chunk 조정 후:
top 3 포함률 84%

하이브리드 검색 추가 후:
top 3 포함률 89%

이렇게 측정해야 어떤 개선이 효과가 있었는지 알 수 있다.

top 3 포함률은 기대한 문서가 검색 결과 상위 3개 안에 포함되는 비율이다.
RAG 검색 품질을 간단히 확인할 때 사용할 수 있다.

6. 관련 없는 문서가 섞이는 문제를 줄인다

RAG 검색에서 기대 문서가 포함되는 것도 중요하지만, 관련 없는 문서가 너무 많이 섞이지 않는 것도 중요하다.

예를 들어 사용자가 이렇게 물었다고 해보자.

하트 환불 기준 알려줘.

검색 결과가 다음과 같다면 문제가 있다.

1. 하트 충전 방법
2. 하트 후원 이벤트 안내
3. 하트 랭킹 정책
4. 하트 환불 기준
5. 하트 아이콘 디자인 가이드

기대 문서인 “하트 환불 기준”이 있긴 하지만 4번째다.

앞에 불필요한 문서가 많다.

이 경우 AI에게 top 5를 모두 전달하면 답변에 불필요한 내용이 섞일 수 있다.

관련 없는 문서가 섞이는 원인은 여러 가지다.

- 문서 제목이 비슷하다.
- chunk가 너무 크다.
- 문서 안에 여러 주제가 섞여 있다.
- 키워드는 같지만 의미가 다르다.
- 메타데이터 필터가 부족하다.
- 벡터 검색만 사용하고 있다.

해결 방법도 여러 가지다.

- chunk를 더 작은 의미 단위로 나눈다.
- 문서 제목과 섹션명을 명확히 한다.
- 문서 유형 필터를 적용한다.
- 키워드 검색을 함께 사용한다.
- reranking을 적용한다.
- 최신 승인 문서를 우선한다.

예를 들어 “환불” 관련 질문은 환불 정책 문서와 결제 처리 매뉴얼을 우선하도록 문서 유형을 사용할 수 있다.

질문에 “환불”이 포함됨
→ documentType = refund_policy, payment_manual 우선 검색

또 “하트”라는 단어만으로 너무 많은 문서가 검색된다면,
“환불”, “미반영”, “결제”, “취소” 같은 키워드와 함께 재정렬할 수 있다.

RAG 검색은 단순히 가장 비슷한 문서를 가져오는 것이 아니다.

질문 의도에 맞는 문서를 골라내는 과정이다.

7. chunk 품질을 개선한다

검색 품질이 낮을 때 가장 먼저 의심해야 할 것 중 하나가 chunk다.

문서가 잘못 나뉘어 있으면 검색 결과가 불안정해진다.

7.1 chunk가 너무 큰 경우

chunk가 너무 크면 여러 주제가 섞인다.

chunk 예시:
하트 충전, 환불, 정산, 이벤트 보상, 고객 공지, 운영자 권한에 대한 내용이 모두 포함됨

이런 chunk는 여러 질문에 애매하게 걸린다.

사용자가 환불을 물어도 검색되고,
충전을 물어도 검색되고,
정산을 물어도 검색된다.

결과적으로 답변에 불필요한 정보가 섞일 수 있다.

7.2 chunk가 너무 작은 경우

반대로 chunk가 너무 작으면 문맥이 부족하다.

chunk 예시:
먼저 승인 여부를 확인한다.

이 문장만 보면 무엇의 승인인지 알 수 없다.

PG 승인인지, 관리자 승인인지, 환불 승인인지 불명확하다.

좋은 chunk는 하나의 질문에 답할 수 있을 만큼의 문맥을 가져야 한다.

좋은 chunk 예시:
하트 충전 후 서비스에 반영되지 않은 경우,
먼저 PG 승인 여부를 확인한다.
PG 승인이 완료되었지만 서비스 충전 내역이 없는 경우,
충전 처리 로그를 확인하고 재처리 대상인지 판단한다.

이 chunk는 “하트 충전 미반영” 질문에 직접 답할 수 있다.

7.3 제목과 섹션을 함께 넣는다

chunk 본문만 저장하는 것보다 제목과 섹션을 함께 넣는 것이 좋다.

제목:
결제 실패 및 하트 미반영 처리 매뉴얼

섹션:
2. 충전 미반영 처리

본문:
PG 승인 완료 후 서비스 충전 내역이 없는 경우 충전 처리 로그를 확인한다.

이렇게 하면 검색도 좋아지고 출처 표시도 쉬워진다.

chunk 품질을 개선하면 RAG 품질이 크게 좋아질 수 있다.

8. 문서 제목과 섹션명을 정리한다

RAG 검색 품질은 문서 제목과 섹션명에도 영향을 받는다.

문서 내용이 좋아도 제목이 애매하면 검색과 출처 표시가 어려워진다.

나쁜 제목 예시는 다음과 같다.

회의 정리
운영 문서
정책 수정
관리자 기능
개발 참고

이런 제목은 사람이 봐도 무엇에 대한 문서인지 알기 어렵다.

RAG도 마찬가지다.

좋은 제목은 문서의 주제를 명확히 드러내야 한다.

결제 실패 및 하트 미반영 처리 매뉴얼
회원 탈퇴 및 재가입 제한 정책
개인정보 포함 엑셀 다운로드 권한 정책
방송방 입장 장애 대응 절차
관리자 권한 신청 및 승인 절차

섹션명도 중요하다.

나쁜 섹션명은 다음과 같다.

개요
처리
기타
주의사항

이런 제목만으로는 내용을 알기 어렵다.

더 좋은 섹션명은 다음과 같다.

2. PG 승인 완료 후 하트 미반영 처리
3. 이미 사용된 하트의 환불 제한
4. 개인정보 포함 엑셀 다운로드 승인 기준
5. 방송방 입장 실패 시 Redis 확인 절차

RAG에서는 문서 제목과 섹션명이 검색 결과와 출처에 사용된다.

근거:
결제 실패 및 하트 미반영 처리 매뉴얼 > 2. PG 승인 완료 후 하트 미반영 처리

이렇게 출처가 표시되면 사용자가 원문을 확인하기 쉽다.

문서 제목 정리는 단순한 문서 관리 작업처럼 보이지만, RAG 품질 개선에 직접적인 영향을 준다.

9. 메타데이터를 활용해 검색 범위를 줄인다

RAG 검색 품질을 높이려면 모든 문서를 대상으로 검색하지 않는 것이 좋다.

질문에 따라 검색 범위를 줄일 수 있다.

예를 들어 문서에 다음 메타데이터가 있다고 하자.

{
  "title": "결제 실패 및 하트 미반영 처리 매뉴얼",
  "documentType": "customer_support",
  "domain": "payment",
  "status": "approved",
  "allowedRoles": [
    "operation_manager",
    "admin"
  ],
  "updatedAt": "2026-05-01"
}

이 메타데이터를 사용하면 검색 범위를 제한할 수 있다.

status = approved 문서만 검색
allowedRoles에 사용자 role이 포함된 문서만 검색
domain = payment 문서 우선 검색
documentType = customer_support 문서 우선 검색

예를 들어 사용자가 결제 관련 질문을 했다.

하트 충전했는데 반영이 안 됐어요.

이때 모든 문서를 검색하는 대신 결제 도메인 문서를 우선할 수 있다.

domain = payment
status = approved
allowedRoles contains operation_manager

그러면 검색 품질이 좋아지고, 관련 없는 문서가 줄어든다.

메타데이터는 다음 용도로 사용할 수 있다.

- 권한 필터
- 문서 상태 필터
- 도메인 필터
- 문서 유형 필터
- 최신 문서 우선순위
- 부서별 문서 검색

메타데이터가 없으면 벡터 검색 점수에만 의존해야 한다.

하지만 벡터 검색은 의미적으로 비슷한 문서를 찾는 데 강할 뿐,
문서 상태나 권한, 최신성을 자동으로 판단하지는 못한다.

그래서 RAG 품질을 높이려면 문서 내용과 함께 메타데이터를 잘 관리해야 한다.

10. 오래된 문서와 중복 문서를 정리한다

RAG 품질을 떨어뜨리는 대표적인 원인이 오래된 문서와 중복 문서다.

예를 들어 환불 정책에 대해 문서가 여러 개 있다고 해보자.

2023년 환불 정책 초안
2024년 환불 정책 개정안
2025년 임시 운영 메모
2026년 최신 환불 정책

사용자가 환불 기준을 물었을 때, RAG가 2023년 문서를 가져오면 잘못된 답변을 할 수 있다.

그래서 문서 상태 관리가 필요하다.

draft:
초안, 검색 대상 제외

review:
검토 중, 기본 검색 대상 제외

approved:
승인된 문서, 검색 대상 포함

deprecated:
폐기된 문서, 검색 대상 제외

오래된 문서는 반드시 검색에서 제외하거나 낮은 우선순위로 내려야 한다.

중복 문서도 문제다.

같은 내용을 여러 문서가 조금씩 다르게 설명하면 AI가 혼란스러워할 수 있다.

문서 A:
회원 탈퇴 후 7일 동안 재가입 제한

문서 B:
회원 탈퇴 후 30일 동안 재가입 제한

문서 C:
회원 탈퇴 후 일정 기간 재가입 제한

이런 상태에서 RAG를 만들면 AI 답변도 흔들린다.

문서 정리는 RAG 도입 전 반드시 필요한 작업이다.

- 최신 문서만 approved 상태로 관리
- 오래된 문서는 deprecated 처리
- 중복 문서는 통합
- 초안 문서는 검색 제외
- 문서 소유자와 검토 주기 지정

RAG는 문서 기반 시스템이다.

문서가 어지러우면 AI 답변도 어지러워진다.

11. 하이브리드 검색을 사용한다

벡터 검색은 의미 검색에 강하다.

하지만 정확한 키워드가 중요한 경우에는 약할 수 있다.

예를 들어 사용자가 이렇게 묻는다.

ERR_PAYMENT_409가 발생하면 어떻게 처리해?

이 경우 중요한 것은 ERR_PAYMENT_409라는 정확한 에러 코드다.

벡터 검색만 사용하면 의미상 비슷한 결제 오류 문서를 가져올 수는 있지만,
정확히 해당 에러 코드가 있는 문서를 놓칠 수 있다.

반대로 키워드 검색만 사용하면 사용자가 자연어로 표현한 질문을 놓칠 수 있다.

하트 충전했는데 안 들어왔어요.

문서에는 이렇게 적혀 있을 수 있다.

PG 승인 완료 후 재화 지급 이력이 없는 경우 충전 처리 로그를 확인한다.

이 경우 벡터 검색이 더 유리하다.

그래서 실무에서는 둘을 함께 사용하는 하이브리드 검색이 좋다.

사용자 질문
→ 키워드 검색
→ 벡터 검색
→ 결과 병합
→ 중복 제거
→ 점수 재계산
→ 상위 문서 선택

하이브리드 검색은 다음 상황에 특히 유용하다.

- API 이름과 자연어 질문이 섞여 있을 때
- 에러 코드가 포함된 질문
- 내부 용어가 많은 문서
- 사용자 표현과 문서 표현이 다른 경우
- 정확한 문자열과 의미 검색이 모두 필요한 경우

예를 들어 다음 질문은 하이브리드 검색에 적합하다.

POST /broadcast/start에서 IVS 채널 생성 실패하면 어떻게 돼?

이 질문에는 정확한 API 경로도 있고, 자연어 의미도 있다.

키워드 검색:
POST /broadcast/start

벡터 검색:
IVS 채널 생성 실패 처리 절차

둘을 함께 쓰면 더 좋은 검색 결과를 얻을 수 있다.

하이브리드 검색은 키워드 검색과 벡터 검색을 함께 사용하는 방식이다.
정확한 문자열 검색과 의미 기반 검색을 동시에 활용할 수 있다.

12. reranking으로 검색 결과를 다시 정렬한다

1차 검색 결과가 항상 최적의 순서로 나오지는 않는다.

이때 reranking을 사용할 수 있다.

reranking은 검색된 후보 문서들을 다시 평가해서 질문과 더 관련 있는 문서를 위로 올리는 과정이다.

예를 들어 사용자가 이렇게 물었다고 하자.

하트 충전 후 반영이 안 됐을 때 환불 가능한가요?

1차 검색 결과가 다음과 같을 수 있다.

1. 하트 충전 미반영 처리 매뉴얼
2. 하트 충전 방법 안내
3. 환불 처리 기준
4. 결제 승인 확인 절차
5. 하트 이벤트 정책

질문에는 “환불 가능한가요?”가 포함되어 있다.

따라서 “환불 처리 기준”이 더 중요할 수 있다.

reranking 후에는 이렇게 바뀔 수 있다.

1. 환불 처리 기준
2. 하트 충전 미반영 처리 매뉴얼
3. 결제 승인 확인 절차
4. 하트 충전 방법 안내
5. 하트 이벤트 정책

reranking은 다음 경우에 유용하다.

- 검색 결과는 대체로 맞지만 순서가 아쉬울 때
- top_k를 많이 가져온 뒤 최종 후보를 줄이고 싶을 때
- 질문이 복합적일 때
- 관련 없는 문서가 섞일 때

하지만 단점도 있다.

- 추가 비용이 발생할 수 있다.
- 응답 시간이 늘어날 수 있다.
- 구현이 복잡해질 수 있다.

처음 RAG를 만들 때는 벡터 검색과 메타데이터 필터로 시작하고,
검색 결과 순서가 자주 문제될 때 reranking을 추가하는 것이 좋다.

reranking은 1차 검색 결과를 다시 평가해 더 관련 있는 문서를 위로 올리는 과정이다.

13. 문서에 없는 내용은 답하지 않게 해야 한다

RAG 품질에서 매우 중요한 것은 “잘 답하는 것”만이 아니다.

“답하면 안 되는 질문에 답하지 않는 것”도 중요하다.

사용자가 이렇게 묻는다고 해보자.

파트너 정산 예외 승인자는 누구야?

검색된 문서에 답이 없다면 AI는 이렇게 답해야 한다.

제공된 문서에서는 파트너 정산 예외 승인자를 확인할 수 없습니다.
정산 정책 문서 또는 담당 부서 확인이 필요합니다.

하지만 프롬프트가 약하면 AI는 일반적인 답을 만들어낼 수 있다.

일반적으로 팀장 또는 재무 담당자가 승인합니다.

이 답변은 그럴듯하지만 근거가 없다.

RAG에서는 이런 답변을 막아야 한다.

프롬프트에 명확한 규칙을 넣어야 한다.

규칙:
- 제공된 문서에 있는 내용만 답변해.
- 문서에 없는 내용은 추측하지 마.
- 일반적인 지식으로 보완하지 마.
- 답을 찾을 수 없으면 "제공된 문서에서 확인할 수 없습니다"라고 답해.
- 추가 확인이 필요한 문서나 담당 부서를 제안해.

답변 형식도 도움이 된다.

## 답변
## 근거 문서
## 추가 확인 필요

검색 결과가 부족한 경우에는 답변이 이렇게 나와야 한다.

## 답변
제공된 문서에서는 해당 내용을 확인할 수 없습니다.

## 근거 문서
없음

## 추가 확인 필요
정산 정책 문서 또는 재무 담당자 확인이 필요합니다.

AI가 모르는 것을 아는 척하지 않게 만드는 것이 RAG 품질의 핵심이다.

14. 답변에 출처를 강제한다

RAG 답변에는 출처가 있어야 한다.

출처가 없으면 사용자가 답변을 검증하기 어렵다.

예를 들어 다음 답변은 위험하다.

이미 사용된 하트는 환불할 수 없습니다.

맞는 말일 수도 있지만, 근거가 없다.

더 좋은 답변은 다음과 같다.

이미 후원에 사용된 하트는 환불 대상에서 제외됩니다.

근거:
- 환불 처리 기준 > 3. 사용된 재화의 환불 제한

출처를 표시하면 사용자는 원문을 확인할 수 있다.

또 품질 문제가 생겼을 때 원인 분석이 쉽다.

답변이 틀림
→ 어떤 문서가 근거로 사용됐는지 확인
→ 문서가 오래됐는지 확인
→ 검색이 잘못됐는지 확인
→ AI가 문서를 잘못 해석했는지 확인

출처 표시는 프롬프트에서 강제해야 한다.

답변에는 반드시 근거 문서를 포함해.

근거 문서에는 다음 정보를 표시해.
- 문서 제목
- 섹션
- 가능하면 문서 링크

출처가 없는 답변은 사용하지 않도록 처리할 수도 있다.

예를 들어 RAG 응답 검증에서 다음 조건을 둘 수 있다.

- 검색 결과가 있는데 출처가 없는 답변이면 실패 처리
- 문서에 없는 주장을 했는데 출처가 없으면 재요청
- 출처가 없는 정책 답변은 화면에 표시하지 않음

RAG의 신뢰도는 AI 문장 자체가 아니라, 그 문장을 검증할 수 있는 근거에서 나온다.

15. 답변 형식을 고정한다

RAG 답변 형식을 고정하면 품질 관리가 쉬워진다.

예를 들어 답변이 매번 자유롭게 나오면 사용자가 보기에는 자연스럽지만, 검토와 운영이 어려울 수 있다.

정책 답변은 다음 형식이 좋다.

## 답변
질문에 대한 직접적인 답변

## 근거 문서
- 문서 제목 > 섹션

## 추가 확인 필요
문서에 없거나 불확실한 항목

장애 대응 답변은 다음 형식이 좋다.

## 확인할 항목
## 우선 조치
## 추가 확인 필요
## 근거 문서

고객센터 상담 보조는 다음 형식이 좋을 수 있다.

## 상담원 안내 요약
## 확인해야 할 정보
## 고객에게 안내 가능한 문구
## 근거 문서

예를 들어 하트 미반영 문의에 대한 답변은 다음처럼 나올 수 있다.

## 상담원 안내 요약
하트 충전 후 반영되지 않은 경우 먼저 PG 승인 여부를 확인해야 합니다.
PG 승인이 완료되었지만 서비스 충전 내역이 없다면 충전 처리 로그를 확인합니다.

## 확인해야 할 정보
- PG 승인 여부
- 서비스 충전 내역
- 충전 처리 로그
- 이미 후원에 사용되었는지 여부

## 고객에게 안내 가능한 문구
결제 승인 여부와 충전 처리 내역을 확인한 뒤 안내드리겠습니다.

## 근거 문서
- 결제 실패 및 하트 미반영 처리 매뉴얼 > 2. 충전 미반영 처리

답변 형식이 고정되면 사용자도 익숙해지고, 응답 검증도 쉬워진다.

또 서비스 화면에 표시하기도 좋다.

답변 영역
근거 문서 영역
추가 확인 영역

RAG 답변은 예쁜 문장보다 일관된 구조가 더 중요할 때가 많다.

16. 잘못된 답변 사례를 모아야 한다

RAG 품질은 한 번에 완성되지 않는다.

운영하면서 잘못된 답변 사례를 모아야 한다.

예를 들어 사용자가 답변에 대해 “도움 안 됨”을 눌렀다고 하자.

이때 단순히 평가만 저장하면 부족하다.

다음 정보를 함께 봐야 한다.

- 사용자 질문
- AI 답변
- 검색된 문서
- 검색 점수
- 사용한 모델
- 프롬프트 버전
- 사용자 피드백
- 실제로 기대했던 문서

잘못된 답변은 유형별로 나눌 수 있다.

검색 실패:
관련 문서를 못 찾음

문서 문제:
검색된 문서가 오래되었거나 틀림

생성 실패:
문서는 맞았지만 AI가 잘못 해석함

권한 문제:
권한 없는 문서가 검색됨

출처 문제:
답변은 했지만 출처가 없거나 틀림

질문 이해 실패:
사용자 질문 의도를 잘못 파악함

유형을 나눠야 개선 방향이 나온다.

예를 들어 검색 실패라면 chunk, embedding, 하이브리드 검색을 봐야 한다.

문서 문제라면 문서 소유자와 최신성을 정리해야 한다.

생성 실패라면 프롬프트나 모델을 개선해야 한다.

권한 문제라면 메타데이터와 필터 로직을 확인해야 한다.

RAG 품질 개선은 실패 사례를 모으고, 원인을 분류하고, 반복적으로 개선하는 과정이다.

17. 사용자 피드백을 받아야 한다

RAG 시스템에는 사용자 피드백이 필요하다.

개발자가 테스트 질문을 아무리 잘 만들어도 실제 사용자의 질문은 더 다양하다.

사용자에게 간단한 피드백 버튼을 제공할 수 있다.

👍 도움이 됨
👎 도움이 안 됨

하지만 이것만으로는 부족할 수 있다.

“도움이 안 됨”의 이유를 선택하게 하면 더 좋다.

도움이 안 된 이유:
- 관련 없는 답변
- 답변이 틀림
- 출처가 없음
- 너무 일반적임
- 원하는 문서를 못 찾음
- 권한 문제로 보임

피드백은 품질 개선에 직접 사용된다.

피드백 수집
→ 실패 유형 분류
→ 검색 결과 확인
→ 문서 또는 프롬프트 개선
→ 테스트 질문 세트에 추가

예를 들어 사용자가 “원하는 문서를 못 찾음”을 선택했다면,
해당 질문과 기대 문서를 테스트 세트에 추가한다.

새 테스트 질문:
하트 충전했는데 카드 승인은 됐고 잔액이 안 늘었어요.

기대 문서:
결제 실패 및 하트 미반영 처리 매뉴얼

이렇게 실제 사용자 질문이 테스트 세트에 쌓이면 RAG 품질이 점점 좋아진다.

사용자 피드백은 단순 만족도 조사가 아니다.

RAG 검색 품질을 개선하기 위한 데이터다.

18. 프롬프트와 모델 변경은 비교 테스트가 필요하다

RAG 품질을 높이려고 프롬프트나 모델을 바꿀 수 있다.

하지만 바꾼 뒤에 “느낌상 좋아졌다”로 판단하면 안 된다.

기존 테스트 질문 세트로 비교해야 한다.

예를 들어 기존 프롬프트가 있다.

v1:
검색된 문서를 보고 질문에 답해줘.

개선된 프롬프트가 있다.

v2:
검색된 문서에 있는 내용만 근거로 답해.
문서에 없는 내용은 추측하지 마.
답변에는 반드시 근거 문서를 포함해.

이제 같은 질문 세트로 v1과 v2를 비교한다.

질문 100개 기준:

v1:
문서 없는 내용 추측 12건
출처 누락 18건

v2:
문서 없는 내용 추측 3건
출처 누락 2건

이렇게 비교하면 개선 효과를 볼 수 있다.

모델 변경도 마찬가지다.

기존 모델:
답변 정확도는 높지만 비용이 비쌈

새 모델:
비용은 낮지만 복합 질문에서 답변 품질 하락

모델과 프롬프트를 바꿀 때는 다음을 비교한다.

- 검색 결과는 동일한가?
- 답변 정확도는 좋아졌는가?
- 문서에 없는 내용 추측이 줄었는가?
- 출처 표시가 잘 되는가?
- 응답 속도는 어떤가?
- 비용은 어떻게 변했는가?

RAG는 프롬프트, 모델, chunk, 검색 방식이 서로 영향을 준다.

변경할 때는 반드시 기준 질문으로 비교해야 한다.

19. RAG 품질 개선 우선순위

RAG 답변이 만족스럽지 않을 때는 어디부터 개선해야 할까?

무작정 모델부터 바꾸는 것은 좋은 방법이 아닐 수 있다.

일반적으로는 다음 순서로 보는 것이 좋다.

1. 문서 품질
2. chunk 품질
3. 검색 품질
4. 프롬프트
5. 모델
6. UI와 피드백

19.1 문서 품질

문서가 틀리면 답변도 틀린다.

- 최신 문서인가?
- 승인된 문서인가?
- 중복 문서가 없는가?
- 충돌하는 문서가 없는가?

19.2 chunk 품질

문서가 잘못 나뉘면 검색이 흔들린다.

- chunk가 너무 크지 않은가?
- chunk가 너무 작지 않은가?
- 제목과 섹션이 포함되어 있는가?
- Q와 A가 분리되지 않았는가?

19.3 검색 품질

기대 문서가 검색되는지 확인한다.

- top 3 안에 기대 문서가 있는가?
- 관련 없는 문서가 많이 섞이는가?
- 권한 필터가 적용되는가?

19.4 프롬프트

검색은 맞는데 답변이 이상하면 프롬프트를 본다.

- 문서 기반 답변을 강제하는가?
- 문서에 없으면 모른다고 하는가?
- 출처 표시를 요구하는가?
- 답변 형식이 명확한가?

19.5 모델

마지막으로 모델을 검토한다.

- 현재 모델이 문서를 잘 이해하는가?
- 긴 컨텍스트를 처리할 수 있는가?
- 한국어 답변 품질이 충분한가?
- 비용과 속도는 적절한가?

대부분의 RAG 문제는 모델보다 문서, chunk, 검색에서 먼저 발생한다.

모델 교체는 필요할 수 있지만, 가장 먼저 할 일은 아니다.

20. 정리

RAG 품질을 높이려면 답변만 보면 안 된다.

RAG는 검색과 생성이 결합된 구조이기 때문에,
검색 품질과 답변 품질을 나눠서 평가해야 한다.

좋은 RAG를 만들려면 먼저 실제 사용자가 물어볼 질문 세트를 만들고,
각 질문에 대해 기대 문서와 기대 답변을 정리해야 한다.

검색 단계에서는 기대 문서가 top 3 또는 top 5 안에 들어오는지 확인해야 한다.
관련 없는 문서가 많이 섞이는지도 봐야 한다.

답변 단계에서는 검색된 문서를 근거로 정확히 답했는지,
문서에 없는 내용을 추측하지 않았는지,
출처를 제대로 표시했는지 확인해야 한다.

RAG 품질 개선은 보통 다음 순서로 진행하는 것이 좋다.

문서 정리
→ chunk 개선
→ 메타데이터 필터 적용
→ 하이브리드 검색
→ reranking
→ 프롬프트 개선
→ 모델 비교
→ 사용자 피드백 반영

RAG는 한 번 만들고 끝나는 기능이 아니다.

사용자 질문이 쌓이고, 문서가 바뀌고, 정책이 변경되면 계속 관리해야 한다.

이 장에서 기억해야 할 핵심은 하나다.

RAG 품질은 AI 모델만의 문제가 아니다.
좋은 문서, 좋은 검색, 좋은 프롬프트, 그리고 지속적인 평가가 함께 만들어내는 결과다.

15장 핵심 요약